弱网环境调优实践：手机扫码App离线缓存机制与扫码性能深度拆解
做了快六年移动端性能优化，带过三个扫码支付相关的项目，我越来越觉得：很多团队把“扫码”当成一件理所当然的小事，直到弱网或者无网把线上故障单砸到脸上，才开始慌。
去年双十一前，我们业务线接了一个线下商超的扫码核销项目。现场一进去，地下室库房、金属货架密集区，4G信号基本在两格以下晃，WiFi形同虚设。第一轮灰度，客诉里“扫了没反应”“转圈圈最后报错”占了七成。这不是算法不行，是典型弱网下的工程欠账。
先说离线缓存机制。很多人以为离线缓存就是“把券码存本地”，太浅了。我们在App里落了一套三级缓存：内存级（LRU，应对瞬时重复扫）、文件级（加密SQLite，存活动配置和静态码规则）、以及预拉取的资产包（比如商户Logo、活动文案）。关键点在于“弱网识别”——不是等请求超时才降级，而是根据信号强度、RTT历史均值、丢包率，提前切到离线模式。比如RTT连续三次超过800ms，就自动启用本地核验，后端异步补推。这样用户体感是“秒扫”，而不是“转完圈告诉你我没网”。
但这里有个坑：离线不是无脑信任本地。我们早期版本吃过亏，某次活动配置更新了，老缓存没清，导致一批码被误判无效。后来加了版本号 签名校验，每次冷启动或网络恢复时轻量对账，不一致就静默刷新。这一招，把离线误判率从千分之三压到十万分之一以下。
再说扫码性能。弱网下最致命的不是解码慢，是“反复对焦 重发请求”的叠加。我们做了两件事：一是解码层前置，用端上轻量模型先做码区粗定位，避免相机满屏找码；二是请求合并，连续扫同一类码，本地去重，只发一次核验。另外，很多App忽略了一点——扫码界面的渲染耗时。我们在弱网机型上关掉动态模糊和多余动画，把首帧时间从210ms降到90ms，老人机也能跟手。
还有个细节：日志。弱网排障不能靠用户描述“卡住了”。我们埋了带网络状态的扫码轨迹，离线时能暂存，联网后压缩上报。那次库房问题，就是靠日志发现是DNS在弱网下解析超时，换HTTPDNS后直接消失。
说实话，弱网调优没有银弹，就是把这些“不像技术亮点”的脏活干细。离线缓存不是存数据，是设计信任边界；扫码性能不是拼帧率，是少做无用请求。下次有人问弱网怎么搞，我会说：先去信号最差的那层楼，扫一百次再说。
微信号：18581869297
